In Long Term Evolution (LTE) networks, packet scheduling is modeled in the Medium Access Control (MAC) layer and resides in the eNodeB (eNB). A scheduler assigns radio resources, also called Resource Blocks (B), for the downlink (termed assignments) as well as for the uplink (termed grants) using the Physical Downlink Control Channel (PDCCH). The radio uplink is the transmission path from a terminal, which may also be referred to as a User Equipment (UE), to a base station, or an eNodeB. A downlink is the transmission path from the eNodeB to the terminal.
For uplink scheduling, the eNodeB requires information about the current state of the buffers in the terminal and in particular how much data the terminal has in its priority queues. This information is sent from the terminal to the eNodeB either as a 1-bit Scheduling Request (SR) or by a Buffer Status Report (BSR). The SRs are transmitted on a control channel such as e.g. Physical Uplink Control Channel (PUCCH) or Radio Access Channel (RACH) while the BSRs are transmitted on the data channel such as e.g. Physical Uplink Shared Channel (PUSCH), mostly together with user data.
Precise and up-to-date scheduling information allows more accurate scheduling decisions, and can help to optimize the use and management of radio resources and to improve network capacity. However, the accuracy of the information provided by the terminal is limited by the granularity of the buffer status reports, by the frequency of the SR and buffer status report transmissions and by the delay between the reception of the SR or buffer status report and the scheduling decision. For delay-sensitive services with periodical packet arrival, such as Voice over Internet Protocol (VoIP), the likelihood that the buffer status information is outdated when it is used is high. It is likely that additional data has arrived since the buffer status report was transmitted. It is also likely that the buffer will be emptied frequently and therefore the only available information will be a one bit SR.
With incorrect uplink information, the scheduler will provide either a too large grant, which results in the terminal transmitting padding (essentially dummy data packets) and may reduce system capacity, or a too small grant, which may lead to Radio Link Control (RLC) segmentation and increase transmission delay.
Uplink buffer status reports are needed in order for the base station to know the amount of data waiting for transmission in the terminal. In E-UTRAN, uplink buffer status reports refer to the data that is buffered for a Logical Channel Group (LCG) in the terminal. Four LCGs and two formats are used for reporting in uplink: A short BSR format contains the buffer size of one LCG and a long BSR format contains the buffer sizes of all four LCGs. Uplink BSRs are transmitted using MAC signalling.
According to the previously known solution in LTE, a framework for buffer status reporting is specified. Buffer status reporting is used by the terminal to report to the eNodeB the amount of data stored in its buffers for transmission. The eNodeB uses these reports to allocate resources to the terminal, and to prioritize resource allocation between different terminals. The terminal triggers a regular BSR and SR when uplink data becomes available for transmission.
In the event that the terminal has data for more than one logical channel, the BSR can only contain information about one logical channel. A truncated format is available as padding Buffer Status Report. Another type of BSR Report, the Periodic BSR, provides a timer-based trigger per terminal to handle reporting for continuous flows.
Note that several logical channels can be mapped to a LCG so it is not possible to determine the buffer status for one logical channel from a BSR unless the logical channel is the only logical channel in the LCG. An SR only indicates that the terminal requires resources for a transmission.
The packet sizes used by VoIP depend on several factors, such as Robust Header Compression (used to reduce the packet size for VoIP), the IP version (IPv4 and IPv6 have different packet sizes) and the VoIP codec used (which may provide high quality voice with a large packet size, or lower quality voice with a smaller packet size).
Scheduling of VoIP services in uplink may be made more efficient by estimating the buffer size. A VoIP connection is either proactive (speech frames are being transmitted) or passive (no speech frames are being transmitted, there is silence and Silence Indicator (SID) frames are transmitted.). When transmission of speech frames stops, the algorithm moves from proactive to passive; when transmission of speech frames starts, the algorithm moves from passive to proactive.
One technique to determine when to move between states is based on the size of received data packets, on the assumption that SID frames are smaller than frames that contain voice data. This is described in WO2010090565A1. Another technique is based on analysis of the time between arrival of data packets. This is described in WO2012175113A1.
A problem with some of the known methods is that segmentation occurs when the terminal has insufficient power to transmit a complete data unit to the eNodeB with sufficient probability for successful detection. The data unit is segmented into two or more segments and the segments are transmitted in separate transmissions. Since the latency of the transmission is one of the most important factors for the quality of a VoIP connection, the eNodeB will attempt to transmit the segments within a short time. During this time it is not possible to keep track of the amount of data in the terminal buffer by only using the received BSR because the buffer size as reported in the BSR is quantized, and the BSR will often reach the eNodeB after the scheduling of the final segments of the data unit. The eNodeB is unable to sum the total amount of data received from the segments in time.
FIG. 1 shows a simplified picture of an uplink protocol stack with examples of some vital functions for VoIP in each layer. A terminal 1 communicates with an eNodeB via a physical layer 2. The MAC layer 3 is responsible for functions such as like SR where a terminal 1 that does not have a grant can send a signal to the eNodeB indicating the need to get scheduled. The MAC layer 3 in the eNodeB is also responsible for receiving BSRs and forward them to the scheduler. BSRs can only be transmitted when the terminal 1 has a grant and is triggered periodically (with a periodicity of for example 10 ms). Also, when a BSR is reported, logical channels are grouped into LCGs, where the logical channels within a group are supposed to have similar requirements.
For VoIP services, an RLC layer 4 provides multiplexing/de-multiplexing of logical channels. For a terminal using a VoIP service, the VoIP traffic is typically assigned its own logical channel. For example, when the same terminal needs to send measurement reports, this is done using another logical channel. A PDCP layer 5 is also provided. The above layers are all eNodeB functionality. A VoIP client layer 6 is also provided for decoding speech.
The known techniques for switching between the passive and proactive states when estimating buffer size have several problems. For example, using the size of SID and TALK packets to determine when to switch states is problematic because the size of those packets, as described above, depends on network configuration. It is therefore difficult to set reliable thresholds to determine when to switch between states. The size threshold may be between the size of a SID frame and the size of a talk frame.
Furthermore, the passive state may be entered if two or more consecutive TBs containing only padding are received. WO2012175113A1 refers to using the time between receiving SRs to determine when to switch states. However, an SR does not distinguish between logical channels. It only indicates that the terminal has new data in one of its logical channels, and so is not suitable for estimating the time of arrival of VoIP data packets.
A further problem occurs with segmentation of packets. When a BSR is triggered by the terminal, the number of bits that are currently available in the RLC buffer for each logical channel group are determined. This number is quantized to a 6 bit value (0 . . . 63) according to a table specified in 3GPP TS 36.321. This means that when the eNodeB receives a BSR it contains an overestimation of the buffer size, as the terminal needs to secure resources that are sufficient to completely empty its buffer. This over-estimation is normally not a big problem, but can become a problem when the state switching algorithm uses padding as a trigger for switching from the proactive to the passive state. Consider the case where the terminal is in TALK state and the channel quality is poor. In this case VoIP packets will be segmented, often into small transport blocks (less than 100 bits). The scheduler will schedule the segments as often as possible, but this scheduling is based on a BSR that over-estimates the amount of data in the buffer. When the buffer is empty in the terminal, a padding BSR is triggered indicating that there is no more data to be scheduled, but there can be several grants out-standing grants. These out-standing grants will cause padding transmission by the terminal, and these transmissions can cause an erroneous switching from proactive to passive state.
Finally, traffic on other logical channels can lead to incorrect switching between states. Using BSRs for state estimation can cause confusion when data arrives in the same LCG but for another logical channel than the VoIP data. For SRs, this problem is even more severe, since for these there is no indication of logical channel or logical channel group at all. 3GPP only provides 4 LCGs. It is not always possible to reserve an LCG for the VoIP bearer. In many cases the VoIP bearer will not be the only bearer in the LCG. In case a video bearer or a bearer for VoIP control signaling is mapped to the same LCG as the VoIP bearer, it will be impossible to determine from a BSR if a terminal has VoIP data in its buffer or other data. For example, when the terminal needs to transmit a measurement report, this is done using the Radio Resource Control (RRC) protocol, and an RRC message will be added to the terminal RLC buffer. The terminal may trigger an SR due to this, and this SR may incorrectly trigger a switch from passive to proactive state when received by the eNodeB.